Re: [openstack-dev] [tripleo] storyboard evaluation

[David Moreau Simard]

I have nothing to add but I wanted to mention that it seems like a
great exercise to have UI/UX minded folks test our Storyboard
implementation.

Storyboard will be what we make of it based on the feedback and
contributions it gets. It's an interesting opportunity.
I'd actually like to encourage Horizon and the different UI components
developers to test Storyboard, provide feedback and contribute !

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Fri, Mar 2, 2018 at 4:24 AM, Emilien Macchi  wrote:
> A quick update:
>
> - Discussed with Jiri Tomasek from TripleO UI squad and he agreed that his
> squad would start to use Storyboard, and experiment it.
> - I told him I would take care of making sure all UI bugs created in
> Launchpad would be moved to Storyboard.
> - Talked with Kendall and we agreed that we would move forward and migrate
> TripleO UI bugs to Storyboard.
> - TripleO UI Squad would report feedback about storyboard to the storyboard
> team with the help of other TripleO folks (me at least, I'm willing to
> help).
>
> Hopefully this is progress and we can move forward. More updates to come
> about migration during the next days...
>
> Thanks everyone involved in these productive discussions.
>
> On Wed, Jan 17, 2018 at 12:33 PM, Thierry Carrez 
> wrote:
>>
>> Clint Byrum wrote:
>> > [...]
>> > That particular example board was built from tasks semi-automatically,
>> > using a tag, by this script running on a cron job somewhere:
>> >
>> >
>> > https://git.openstack.org/cgit/openstack-infra/zuul/tree/tools/update-storyboard.py?h=feature/zuulv3
>> >
>> > We did this so that we could have a rule "any task that is open with
>> > the zuulv3 tag must be on this board". Jim very astutely noticed that
>> > I was not very good at being a robot that did this and thus created the
>> > script to ease me into retirement from zuul project management.
>> >
>> > The script adds new things in New, and moves tasks automatically to
>> > In Progress, and then removes them when they are completed. We would
>> > periodically groom the "New" items into an appropriate lane with the
>> > hopes
>> > of building what you might call a rolling-sprint in Todo, and calling
>> > out blocked tasks in a regular meeting. Stories were added manually as
>> > a way to say "look in here and add tasks", and manually removed when
>> > the larger effort of the story was considered done.
>> >
>> > I rather like the semi-automatic nature of it, and would definitely
>> > suggest that something like this be included in Storyboard if other
>> > groups find the board building script useful. This made a cross-project
>> > effort between Nodepool and Zuul go more smoothly as we had some more
>> > casual contributors to both, and some more full-time.
>>
>> That's a great example that illustrates StoryBoard design: rather than
>> do too much upfront feature design, focus on primitives and expose them
>> fully through a strong API, then let real-world usage dictate patterns
>> that might result in future features.
>>
>> The downside of this approach is of course getting enough usage on a
>> product that appears a bit "raw" in terms of features. But I think we
>> are closing on getting that critical mass :)
>>
>> --
>> Thierry Carrez (ttx)
>>
>> __
>> 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
>
>
>
>
> --
> Emilien Macchi
>
> __
> 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 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

Re: [openstack-dev] [tripleo][ui] Dependency management

[Alan Pevec]

On Mon, Jan 22, 2018 at 9:30 AM, Julie Pichon  wrote:
> On 19 January 2018 at 18:43, Honza Pokorny  wrote:
>> We've recently discovered an issue with the way we handle dependencies for
>> tripleo-ui.  This is an explanation of the problem, and a proposed solution.
>> I'm looking for feedback.
>>
>> Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for
>> tripleo-ui:
>>
>> * Native npm jobs
>> * Undercloud integration jobs
>>
>> After the upgrade, the integration jobs went away.  Our goal is to add them
>> back.
>>
>> There is a difference in how these two types of jobs handle dependencies.
>> Native npm jobs use the "npm install" command to acquire packages, and
>> undercloud jobs use RPMs.  The tripleo-ui project uses a separate RPM for
>> dependencies called openstack-tripleo-ui-deps.
>>
>> Because of the requirement to use a separate RPM for dependencies, there is 
>> some
>> extra work needed when a new dependency is introduced, or an existing one is
>> upgraded.  Once the patch that introduces the dependency is merged, we have 
>> to
>> increment the version of the -deps package, and rebuild it.  It then shows 
>> up in
>> the yum repos used by the undercloud.
>>
>> To make matters worse, we recently upgraded our infrastructure to nodejs 
>> 8.9.4
>> and npm 5.6.0 (latest stable).  This makes it so we can't write "purist" 
>> patches
>> that simply introduce a new dependency to package.json, and nothing more.  
>> The
>> code that uses the new dependency must be included.  I tend to think that 
>> each
>> commit should work on its own so this can be seen as a plus.
>>
>> This presents a problem: you can't get a patch that introduces a new 
>> dependency
>> merged because it's not included in the RPM needed by the undercloud ci job.
>>
>> So, here is a proposal on how that might work:
>>
>> 1. Submit a patch for review that introduces the dependency, along with code
>>changes to support it and validate its inclusion
>> 2. Native npm jobs will pass
>> 3. Undercloud gate job will fail because the dependency isn't in -deps RPM
>> 4. We ask RDO to review for licensing
>> 5. Once reviewed, new -deps package is built
>> 6. Recheck
>> 7. All jobs pass
>
> Perhaps there should be a step after 3 or 4 to have the patch normally
> reviewed, and wait for it to have two +2s before building the new
> package? Otherwise we may end up with wasted work to get a new package
> ready for dependencies that were eventually dismissed.

Thanks Julie for reminding me of  this thread!

I agree we can only build ui-deps package when the review is about to merge.
I've proposed https://github.com/rdo-common/openstack-tripleo-ui-deps/pull/19
which allows us to build the package with the review and patchset
numbers, before it's merged.
Please review and we can try it on the next deps update!

Cheers,
Alan

__
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

Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

[Duncan Thomas]

Met with Jay, looking at alternatives

On 2 Mar 2018 6:26 pm, "Duncan Thomas"  wrote:

> I'm in the pub now, and they are closing down
>
> On 2 Mar 2018 5:48 pm, "Jay S. Bryant"  wrote:
>
>> Ivan,
>>
>> I sent another note but will also respond in this thread.
>>
>> Yes, they will serve us tonight.  It is a somewhat limited menu but I
>> stopped to look at it and it still looked good.
>>
>> Sidewalks on the way to the restaurant were not in too bad of shape.
>>
>> Jay
>>
>> On 3/2/2018 10:48 AM, Ivan Kolodyazhny wrote:
>>
>> Hi Jay,
>>
>> Will Fagans serve us tonight?
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant 
>> wrote:
>>
>>>
>>>
>>> On 3/1/2018 6:50 AM, Sean McGinnis wrote:
>>>
 On Feb 28, 2018, at 16:58, Jay S Bryant  wrote:
>
> Team,
>
> Just a reminder that we will be having our team photo at 9 am tomorrow
> before the Cinder/Nova cross project session.  Please be at the
> registration desk before 9 to be in the photo.
>
> We will then have the Cross Project session in the Nova room as it
> sounds like it is somewhat larger.  I will have sound clips in hand to 
> make
> sure things don't get too serious.
>
> Finally, an update on dinner for tomorrow night.  I have moved dinner
> to a closer venue:
>
> Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower, Drumcondra,
> Dublin 9
>
> I have reservations for 7:30 pm.  It isn't too difficult a walk from
> Croke Park (even in a blizzard) and it is a great pub.
>
> Thanks for a great day today!
>
> See you all tomorrow!  Let's make it a great one!  ;-)
> Jay
>
> Any plan now that there is a 4pm curfew?

 Dinner has been rescheduled for Friday night 3/2 or 2/3 depending on
>>> your country of origin.  6:30 at Fagans.
>>>
>>> I will update the etherpad.
>>>
>>> Jay
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> 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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Kaz Shinohara]

Hi Thomas(zigo),

I found an issue which is included in
https://review.openstack.org/#/c/548924/ (you did cherry pick last
night)
In short, this issue makes it impossible to install heat-dashboard..

I landed fix for this.  https://review.openstack.org/#/c/549214/

Could you kindly pick up this for your package ?
Sorry again for your inconvenience.

Regards,
Kaz(kazsh)


2018-03-02 23:37 GMT+09:00 Akihiro Motoki :
> Thanks for clarification.
> I was a bit confused with the two things because the patch dropped
> some embedded stuffs like font-awesome.
> Let's address the "embedded" problem soon :)
>
> Akihiro
>
> 2018-03-02 14:27 GMT+00:00 Xinni Ge :
>> Hi, Akihiro,
>>
>> The patch I submitted previously didn't solve the embedded problem.
>> I would like to fix out the whole thing in several steps, because the
>> current status of static files arrangment is quite messy.
>>
>> I will upload the javascript and css style files as xstatic-* projects and
>> remove them from the code later on.
>>
>> I wanted to solve the unittest problem ASAP and assumed it will take some
>> time to create xstatic repos and get the approval from infra team,
>> so I just submitted this patch to let unittest go well at first.
>>
>> Thanks for asking, I am happy to hear from your all about the js and static
>> files issue.
>>
>> Best regards,
>>
>> Xinni
>>
>> On Fri, Mar 2, 2018 at 1:29 PM, Akihiro Motoki  wrote:
>>>
>>> Hi Xinni,
>>>
>>> I looked at your patch which drops the vendors stuffs, but I still
>>> have a question.
>>>
>>> The patch introduces some SCSS like:
>>> - bootstrap.scss
>>> - angular-notify.scss
>>> - angular-material.scss
>>>
>>> Aren't they another type of "vendors" stuffs?
>>> I don't understand why switching to SCSS solves the embedded "vendors"
>>> problem?
>>>
>>> I would like to know opinions from zigo and Corey.
>>>
>>> Thanks,
>>> Akihiro
>>>
>>>
>>> 2018-03-01 21:30 GMT+00:00 Xinni Ge :
>>> > Hi, there.
>>> >
>>> > This is a page of a similar unittest issue.
>>> > https://bugs.launchpad.net/heat-dashboard/+bug/1752527
>>> >
>>> > We merged the following patch to fix the issue, and hope it also fix the
>>> > trouble described here.
>>> >  https://review.openstack.org/#/c/548924/
>>> >
>>> > As for the minified javascript files, we are working on removing from
>>> > the
>>> > source code,
>>> >  and uploading as xstatic packages.
>>> > Just need a little more time to finish it.
>>> >
>>> >
>>> > Best regards,
>>> >
>>> > Xinni
>>> >
>>> > On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand 
>>> > wrote:
>>> >>
>>> >> On 02/23/2018 09:29 AM, Xinni Ge wrote:
>>> >> > Hi there,
>>> >> >
>>> >> > We are aware of the javascript embedded issue, and working on it now,
>>> >> > the patch will be summited later.
>>> >> >
>>> >> > As for the unittest failure, we are still investigating it. We will
>>> >> > contant you as soon as we find out the cause.
>>> >> >
>>> >> > Sorry to bring troubles to you. We will be grateful if you could wait
>>> >> > for a little longer.
>>> >> >
>>> >> > Best Regards,
>>> >> >
>>> >> > Xinni
>>> >>
>>> >> Hi,
>>> >>
>>> >> Thanks for this message. This lowers the frustration! :)
>>> >> Let me know if there's any patch I could review.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Thomas Goirand (zigo)
>>> >>
>>> >>
>>> >> __
>>> >> 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
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > 葛馨霓 Xinni Ge
>>> >
>>> >
>>> > __
>>> > 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 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
>>
>>
>>
>>
>> --
>> 葛馨霓 Xinni Ge
>>
>> __
>> 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 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

Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

[Duncan Thomas]

I'm in the pub now, and they are closing down

On 2 Mar 2018 5:48 pm, "Jay S. Bryant"  wrote:

> Ivan,
>
> I sent another note but will also respond in this thread.
>
> Yes, they will serve us tonight.  It is a somewhat limited menu but I
> stopped to look at it and it still looked good.
>
> Sidewalks on the way to the restaurant were not in too bad of shape.
>
> Jay
>
> On 3/2/2018 10:48 AM, Ivan Kolodyazhny wrote:
>
> Hi Jay,
>
> Will Fagans serve us tonight?
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant  wrote:
>
>>
>>
>> On 3/1/2018 6:50 AM, Sean McGinnis wrote:
>>
>>> On Feb 28, 2018, at 16:58, Jay S Bryant  wrote:

 Team,

 Just a reminder that we will be having our team photo at 9 am tomorrow
 before the Cinder/Nova cross project session.  Please be at the
 registration desk before 9 to be in the photo.

 We will then have the Cross Project session in the Nova room as it
 sounds like it is somewhat larger.  I will have sound clips in hand to make
 sure things don't get too serious.

 Finally, an update on dinner for tomorrow night.  I have moved dinner
 to a closer venue:

 Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower, Drumcondra,
 Dublin 9

 I have reservations for 7:30 pm.  It isn't too difficult a walk from
 Croke Park (even in a blizzard) and it is a great pub.

 Thanks for a great day today!

 See you all tomorrow!  Let's make it a great one!  ;-)
 Jay

 Any plan now that there is a 4pm curfew?
>>>
>>> Dinner has been rescheduled for Friday night 3/2 or 2/3 depending on
>> your country of origin.  6:30 at Fagans.
>>
>> I will update the etherpad.
>>
>> Jay
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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 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

Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

[Jay S. Bryant]

Ivan,

I sent another note but will also respond in this thread.

Yes, they will serve us tonight.  It is a somewhat limited menu but I 
stopped to look at it and it still looked good.


Sidewalks on the way to the restaurant were not in too bad of shape.

Jay


On 3/2/2018 10:48 AM, Ivan Kolodyazhny wrote:

Hi Jay,

Will Fagans serve us tonight?

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant > wrote:




On 3/1/2018 6:50 AM, Sean McGinnis wrote:

On Feb 28, 2018, at 16:58, Jay S Bryant
> wrote:

Team,

Just a reminder that we will be having our team photo at 9
am tomorrow before the Cinder/Nova cross project session. 
Please be at the registration desk before 9 to be in the
photo.

We will then have the Cross Project session in the Nova
room as it sounds like it is somewhat larger.  I will have
sound clips in hand to make sure things don't get too serious.

Finally, an update on dinner for tomorrow night.  I have
moved dinner to a closer venue:

Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower,
Drumcondra, Dublin 9

I have reservations for 7:30 pm.  It isn't too difficult a
walk from Croke Park (even in a blizzard) and it is a
great pub.

Thanks for a great day today!

See you all tomorrow!  Let's make it a great one!  ;-)
Jay

Any plan now that there is a 4pm curfew?

Dinner has been rescheduled for Friday night 3/2 or 2/3 depending
on your country of origin.  6:30 at Fagans.

I will update the etherpad.

Jay


__
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 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] [tripleo] looking for feedback on running triple-quickstart libvirt as root

[Wesley Hayutin]

Greetings,

I've heard from a number of people in the TripleO community that they would
prefer the default libvirt settings for quickstart be changed from user
sessions to root system settings [1].

If you have any thoughts or opinions please share them in the launchpad bug
https://bugs.launchpad.net/tripleo/+bug/1752909

Thanks!


[1]
https://wiki.libvirt.org/page/FAQ#What_is_the_difference_between_qemu:.2F.2F.2Fsystem_and_qemu:.2F.2F.2Fsession.3F_Which_one_should_I_use.3F
__
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] [Blazar] skip next weekly meeting

[Masahito MUROI]

Dear Blazar folks,

We had a great discussion in the Dublin PTG. Unfortunately, most of 
members are still stuck in Dublin because of heavy snow and will not be 
able to back their home by the meeting.


So let's skip the next weekly meeting on 6th March.

best regards,
Masahito


__
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

Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

[Ivan Kolodyazhny]

Hi Jay,

Will Fagans serve us tonight?

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant  wrote:

>
>
> On 3/1/2018 6:50 AM, Sean McGinnis wrote:
>
>> On Feb 28, 2018, at 16:58, Jay S Bryant  wrote:
>>>
>>> Team,
>>>
>>> Just a reminder that we will be having our team photo at 9 am tomorrow
>>> before the Cinder/Nova cross project session.  Please be at the
>>> registration desk before 9 to be in the photo.
>>>
>>> We will then have the Cross Project session in the Nova room as it
>>> sounds like it is somewhat larger.  I will have sound clips in hand to make
>>> sure things don't get too serious.
>>>
>>> Finally, an update on dinner for tomorrow night.  I have moved dinner to
>>> a closer venue:
>>>
>>> Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower, Drumcondra, Dublin
>>> 9
>>>
>>> I have reservations for 7:30 pm.  It isn't too difficult a walk from
>>> Croke Park (even in a blizzard) and it is a great pub.
>>>
>>> Thanks for a great day today!
>>>
>>> See you all tomorrow!  Let's make it a great one!  ;-)
>>> Jay
>>>
>>> Any plan now that there is a 4pm curfew?
>>
>> Dinner has been rescheduled for Friday night 3/2 or 2/3 depending on your
> country of origin.  6:30 at Fagans.
>
> I will update the etherpad.
>
> Jay
>
>
> __
> 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 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

Re: [openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

[James E. Blair]

Bogdan Dobrelya  writes:

> Hello.
> As Zuul documentation [0] explains, the names "check", "gate", and
> "post"  may be altered for more advanced pipelines. Is it doable to
> introduce, for particular openstack projects, multiple check
> stages/steps as check-1, check-2 and so on? And is it possible to make
> the consequent steps reusing environments from the previous steps
> finished with?
>
> Narrowing down to tripleo CI scope, the problem I'd want we to solve
> with this "virtual RFE", and using such multi-staged check pipelines,
> is reducing (ideally, de-duplicating) some of the common steps for
> existing CI jobs.

What you're describing sounds more like a job graph within a pipeline.
See: 
https://docs.openstack.org/infra/zuul/user/config.html#attr-job.dependencies
for how to configure a job to run only after another job has completed.
There is also a facility to pass data between such jobs.

> For example, we may want to omit running all of the OVB or multinode
> (non-upgrade) jobs deploying overclouds, when the *undercloud* fails
> to install. This case makes even more sense, when undercloud is
> deployed from the same heat templates (aka Containerized Undercloud)
> and uses the same packages and containers images, as overcloud would
> do! Or, maybe, just stop the world, when tox failed at the step1 and
> do nothing more, as it makes very little sense to run anything else
> (IMO), if the patch can never be gated with a failed tox check
> anyway...
>
> What I propose here, is to think and discuss, and come up with an RFE,
> either for tripleo, or zuul, or both, of the following scenarios
> (examples are tripleo/RDO CI specific, though you can think of other
> use cases ofc!):
>
> case A. No deduplication, simple multi-staged check pipeline:
>
> * check-1: syntax only, lint/tox
> * check-2 : undercloud install with heat and containers
> * check-3 : undercloud install with heat and containers, build
> overcloud images (if not multinode job type), deploy
> overcloud... (repeats OVB jobs as is, basically)
>
> case B. Full de-duplication scenario (consequent steps re-use the
> previous steps results, building "on-top"):
>
> * check-1: syntax only, lint/tox
> * check-2 : undercloud unstall, reuses nothing from the step1 prolly
> * check-3 : build overcloud images, if not multinode job type, extends
> stage 2
> * check-4:  deploy overcloud, extends stages 2/3
> * check-5: upgrade undercloud, extends stage 2
> * check-6: upgrade overcloud, extends stage 4
> (looking into future...)
> * check-7: deploy openshift/k8s on openstack and do e2e/conformance et
> al, extends either stage 4 or 6
>
> I believe even the simplest 'case A' would reduce the zuul queues for
> tripleo CI dramatically. What do you think folks? See also PTG tripleo
> CI notes [1].
>
> [0] https://docs.openstack.org/infra/zuul/user/concepts.html
> [1] https://etherpad.openstack.org/p/tripleo-ptg-ci

Creating a job graph to have one job use the results of the previous job
can make sense in a lot of cases.  It doesn't always save *time*
however.

It's worth noting that in OpenStack's Zuul, we have made an explicit
choice not to have long-running integration jobs depend on shorter pep8
or tox jobs, and that's because we value developer time more than CPU
time.  We would rather run all of the tests and return all of the
results so a developer can fix all of the errors as quickly as possible,
rather than forcing an iterative workflow where they have to fix all the
whitespace issues before the CI system will tell them which actual tests
broke.

-Jim

__
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

Re: [openstack-dev] [TripleO][CI][QA] Validating HA on upstream

[Raoul Scarazzini]

On 02/03/2018 15:19, Emilien Macchi wrote:
> Talking with clarkb during PTG, we'll need to transform
> tripleo-quickstart-utils into a non-forked repo - or move the roles to
> an existing repo. But we can't continue to maintain this fork.
> Raoul, let us know what you think is best (move repo to OpenStack or
> move modules to an existing upstream repo).
> Thanks,

Hey Emilien,
I prepared this [1] in which some folks started to have a look at, maybe
it's what we need to move on on this.
If you think something else needs to be done, let me know, I'll work on it.

Thanks,

[1] https://review.openstack.org/#/c/548874

-- 
Raoul Scarazzini
ra...@redhat.com

__
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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Akihiro Motoki]

Thanks for clarification.
I was a bit confused with the two things because the patch dropped
some embedded stuffs like font-awesome.
Let's address the "embedded" problem soon :)

Akihiro

2018-03-02 14:27 GMT+00:00 Xinni Ge :
> Hi, Akihiro,
>
> The patch I submitted previously didn't solve the embedded problem.
> I would like to fix out the whole thing in several steps, because the
> current status of static files arrangment is quite messy.
>
> I will upload the javascript and css style files as xstatic-* projects and
> remove them from the code later on.
>
> I wanted to solve the unittest problem ASAP and assumed it will take some
> time to create xstatic repos and get the approval from infra team,
> so I just submitted this patch to let unittest go well at first.
>
> Thanks for asking, I am happy to hear from your all about the js and static
> files issue.
>
> Best regards,
>
> Xinni
>
> On Fri, Mar 2, 2018 at 1:29 PM, Akihiro Motoki  wrote:
>>
>> Hi Xinni,
>>
>> I looked at your patch which drops the vendors stuffs, but I still
>> have a question.
>>
>> The patch introduces some SCSS like:
>> - bootstrap.scss
>> - angular-notify.scss
>> - angular-material.scss
>>
>> Aren't they another type of "vendors" stuffs?
>> I don't understand why switching to SCSS solves the embedded "vendors"
>> problem?
>>
>> I would like to know opinions from zigo and Corey.
>>
>> Thanks,
>> Akihiro
>>
>>
>> 2018-03-01 21:30 GMT+00:00 Xinni Ge :
>> > Hi, there.
>> >
>> > This is a page of a similar unittest issue.
>> > https://bugs.launchpad.net/heat-dashboard/+bug/1752527
>> >
>> > We merged the following patch to fix the issue, and hope it also fix the
>> > trouble described here.
>> >  https://review.openstack.org/#/c/548924/
>> >
>> > As for the minified javascript files, we are working on removing from
>> > the
>> > source code,
>> >  and uploading as xstatic packages.
>> > Just need a little more time to finish it.
>> >
>> >
>> > Best regards,
>> >
>> > Xinni
>> >
>> > On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand 
>> > wrote:
>> >>
>> >> On 02/23/2018 09:29 AM, Xinni Ge wrote:
>> >> > Hi there,
>> >> >
>> >> > We are aware of the javascript embedded issue, and working on it now,
>> >> > the patch will be summited later.
>> >> >
>> >> > As for the unittest failure, we are still investigating it. We will
>> >> > contant you as soon as we find out the cause.
>> >> >
>> >> > Sorry to bring troubles to you. We will be grateful if you could wait
>> >> > for a little longer.
>> >> >
>> >> > Best Regards,
>> >> >
>> >> > Xinni
>> >>
>> >> Hi,
>> >>
>> >> Thanks for this message. This lowers the frustration! :)
>> >> Let me know if there's any patch I could review.
>> >>
>> >> Cheers,
>> >>
>> >> Thomas Goirand (zigo)
>> >>
>> >>
>> >> __
>> >> 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
>> >
>> >
>> >
>> >
>> > --
>> > 葛馨霓 Xinni Ge
>> >
>> >
>> > __
>> > 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 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
>
>
>
>
> --
> 葛馨霓 Xinni Ge
>
> __
> 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 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

Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions

[Jay Pipes]

On 03/02/2018 02:00 PM, Nadathur, Sundar wrote:

Hello Nova team,

     During the Cyborg discussion at Rocky PTG, we proposed a flow for 
FPGAs wherein the request spec asks for a device type as a resource 
class, and optionally a function (such as encryption) in the extra 
specs. This does not seem to work well for the usage model that I’ll 
describe below.


An FPGA device may implement more than one function. For example, it may 
implement both compression and encryption. Say a cluster has 10 devices 
of device type X, and each of them is programmed to offer 2 instances of 
function A and 4 instances of function B. More specifically, the device 
may implement 6 PCI functions, with 2 of them tied to function A, and 
the other 4 tied to function B. So, we could have 6 separate instances 
accessing functions on the same device.


In the current flow, the device type X is modeled as a resource class, 
so Placement will count how many of them are in use. A flavor for ‘RC 
device-type-X + function A’ will consume one instance of the RC 
device-type-X.  But this is not right because this precludes other 
functions on the same device instance from getting used.


One way to solve this is to declare functions A and B as resource 
classes themselves and have the flavor request the function RC. 
Placement will then correctly count the function instances. However, 
there is still a problem: if the requested function A is not available, 
Placement will return an empty list of RPs, but we need some way to 
reprogram some device to create an instance of function A.


Clearly, nova is not going to be reprogramming devices with an instance 
of a particular function.


Cyborg might need to have a separate agent that listens to the nova 
notifications queue and upon seeing an event that indicates a failed 
build due to lack of resources, then Cyborg can try and reprogram a 
device and then try rebuilding the original request.


Best,
-jay

__
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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Xinni Ge]

Hi, Akihiro,

The patch I submitted previously didn't solve the embedded problem.
I would like to fix out the whole thing in several steps, because the
current status of static files arrangment is quite messy.

I will upload the javascript and css style files as xstatic-* projects and
remove them from the code later on.

I wanted to solve the unittest problem ASAP and assumed it will take some
time to create xstatic repos and get the approval from infra team,
so I just submitted this patch to let unittest go well at first.

Thanks for asking, I am happy to hear from your all about the js and static
files issue.

Best regards,

Xinni

On Fri, Mar 2, 2018 at 1:29 PM, Akihiro Motoki  wrote:

> Hi Xinni,
>
> I looked at your patch which drops the vendors stuffs, but I still
> have a question.
>
> The patch introduces some SCSS like:
> - bootstrap.scss
> - angular-notify.scss
> - angular-material.scss
>
> Aren't they another type of "vendors" stuffs?
> I don't understand why switching to SCSS solves the embedded "vendors"
> problem?
>
> I would like to know opinions from zigo and Corey.
>
> Thanks,
> Akihiro
>
>
> 2018-03-01 21:30 GMT+00:00 Xinni Ge :
> > Hi, there.
> >
> > This is a page of a similar unittest issue.
> > https://bugs.launchpad.net/heat-dashboard/+bug/1752527
> >
> > We merged the following patch to fix the issue, and hope it also fix the
> > trouble described here.
> >  https://review.openstack.org/#/c/548924/
> >
> > As for the minified javascript files, we are working on removing from the
> > source code,
> >  and uploading as xstatic packages.
> > Just need a little more time to finish it.
> >
> >
> > Best regards,
> >
> > Xinni
> >
> > On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand 
> wrote:
> >>
> >> On 02/23/2018 09:29 AM, Xinni Ge wrote:
> >> > Hi there,
> >> >
> >> > We are aware of the javascript embedded issue, and working on it now,
> >> > the patch will be summited later.
> >> >
> >> > As for the unittest failure, we are still investigating it. We will
> >> > contant you as soon as we find out the cause.
> >> >
> >> > Sorry to bring troubles to you. We will be grateful if you could wait
> >> > for a little longer.
> >> >
> >> > Best Regards,
> >> >
> >> > Xinni
> >>
> >> Hi,
> >>
> >> Thanks for this message. This lowers the frustration! :)
> >> Let me know if there's any patch I could review.
> >>
> >> Cheers,
> >>
> >> Thomas Goirand (zigo)
> >>
> >> 
> __
> >> 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
> >
> >
> >
> >
> > --
> > 葛馨霓 Xinni Ge
> >
> > 
> __
> > 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 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
>



-- 
葛馨霓 Xinni Ge
__
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

Re: [openstack-dev] [TripleO][CI][QA] Validating HA on upstream

[Emilien Macchi]

Talking with clarkb during PTG, we'll need to transform
tripleo-quickstart-utils into a non-forked repo - or move the roles to an
existing repo. But we can't continue to maintain this fork.

Raoul, let us know what you think is best (move repo to OpenStack or move
modules to an existing upstream repo).


Thanks,

On Fri, Feb 16, 2018 at 3:12 PM, Raoul Scarazzini  wrote:

> On 16/02/2018 15:41, Wesley Hayutin wrote:
> [...]
> > Using galaxy is an option however we would need to make sure that galaxy
> > is proxied across the upstream clouds.
> > Another option would be to follow the current established pattern of
> > adding it to the requirements file [1]
> > Thanks Bogdan, Raoul!
> > [1] https://github.com/openstack/tripleo-quickstart/
> blob/master/quickstart-extras-requirements.txt
>
> This is how we're using it today into the internal pipelines, so once we
> will have the tripleo-ha-utils (or whatever it will be called) it will
> be just a matter of adding it into the file. In the end I think that
> once the project will be created either way of using it will be fine.
>
> Thanks for your involvement on this folks!
>
> --
> Raoul Scarazzini
> ra...@redhat.com
>
> __
> 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
>



-- 
Emilien Macchi
__
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] [Nova] [Cyborg] Tracking multiple functions

[Nadathur, Sundar]

Hello Nova team,
During the Cyborg discussion at Rocky PTG, we proposed a flow for FPGAs 
wherein the request spec asks for a device type as a resource class, and 
optionally a function (such as encryption) in the extra specs. This does not 
seem to work well for the usage model that I'll describe below.

An FPGA device may implement more than one function. For example, it may 
implement both compression and encryption. Say a cluster has 10 devices of 
device type X, and each of them is programmed to offer 2 instances of function 
A and 4 instances of function B. More specifically, the device may implement 6 
PCI functions, with 2 of them tied to function A, and the other 4 tied to 
function B. So, we could have 6 separate instances accessing functions on the 
same device.

In the current flow, the device type X is modeled as a resource class, so 
Placement will count how many of them are in use. A flavor for 'RC 
device-type-X + function A' will consume one instance of the RC device-type-X.  
But this is not right because this precludes other functions on the same device 
instance from getting used.

One way to solve this is to declare functions A and B as resource classes 
themselves and have the flavor request the function RC. Placement will then 
correctly count the function instances. However, there is still a problem: if 
the requested function A is not available, Placement will return an empty list 
of RPs, but we need some way to reprogram some device to create an instance of 
function A.

Regards,
Sundar

__
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] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

[Bogdan Dobrelya]

Hello.
As Zuul documentation [0] explains, the names "check", "gate", and 
"post"  may be altered for more advanced pipelines. Is it doable to 
introduce, for particular openstack projects, multiple check 
stages/steps as check-1, check-2 and so on? And is it possible to make 
the consequent steps reusing environments from the previous steps 
finished with?


Narrowing down to tripleo CI scope, the problem I'd want we to solve 
with this "virtual RFE", and using such multi-staged check pipelines, is 
reducing (ideally, de-duplicating) some of the common steps for existing 
CI jobs.


For example, we may want to omit running all of the OVB or multinode 
(non-upgrade) jobs deploying overclouds, when the *undercloud* fails to 
install. This case makes even more sense, when undercloud is deployed 
from the same heat templates (aka Containerized Undercloud) and uses the 
same packages and containers images, as overcloud would do! Or, maybe, 
just stop the world, when tox failed at the step1 and do nothing more, 
as it makes very little sense to run anything else (IMO), if the patch 
can never be gated with a failed tox check anyway...


What I propose here, is to think and discuss, and come up with an RFE, 
either for tripleo, or zuul, or both, of the following scenarios 
(examples are tripleo/RDO CI specific, though you can think of other use 
cases ofc!):


case A. No deduplication, simple multi-staged check pipeline:

* check-1: syntax only, lint/tox
* check-2 : undercloud install with heat and containers
* check-3 : undercloud install with heat and containers, build overcloud 
images (if not multinode job type), deploy overcloud... (repeats OVB 
jobs as is, basically)


case B. Full de-duplication scenario (consequent steps re-use the 
previous steps results, building "on-top"):


* check-1: syntax only, lint/tox
* check-2 : undercloud unstall, reuses nothing from the step1 prolly
* check-3 : build overcloud images, if not multinode job type, extends 
stage 2

* check-4:  deploy overcloud, extends stages 2/3
* check-5: upgrade undercloud, extends stage 2
* check-6: upgrade overcloud, extends stage 4
(looking into future...)
* check-7: deploy openshift/k8s on openstack and do e2e/conformance et 
al, extends either stage 4 or 6


I believe even the simplest 'case A' would reduce the zuul queues for 
tripleo CI dramatically. What do you think folks? See also PTG tripleo 
CI notes [1].


[0] https://docs.openstack.org/infra/zuul/user/concepts.html
[1] https://etherpad.openstack.org/p/tripleo-ptg-ci

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [PTG] Team Photo Links

[Kendall Nelson]

Hello Everyone!

I uploaded all the photos to dropbox and they are organized by team! Feel
free to download and do what you like with them.

Dropbox:
https://www.dropbox.com/sh/dtei3ovfi7z74vo/AAB6nLiArw8fYBiO-X_vDGyna?dl=0

- Kendall (diablo_rojo)
__
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

Re: [openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Akihiro Motoki]

Hi Xinni,

I looked at your patch which drops the vendors stuffs, but I still
have a question.

The patch introduces some SCSS like:
- bootstrap.scss
- angular-notify.scss
- angular-material.scss

Aren't they another type of "vendors" stuffs?
I don't understand why switching to SCSS solves the embedded "vendors" problem?

I would like to know opinions from zigo and Corey.

Thanks,
Akihiro


2018-03-01 21:30 GMT+00:00 Xinni Ge :
> Hi, there.
>
> This is a page of a similar unittest issue.
> https://bugs.launchpad.net/heat-dashboard/+bug/1752527
>
> We merged the following patch to fix the issue, and hope it also fix the
> trouble described here.
>  https://review.openstack.org/#/c/548924/
>
> As for the minified javascript files, we are working on removing from the
> source code,
>  and uploading as xstatic packages.
> Just need a little more time to finish it.
>
>
> Best regards,
>
> Xinni
>
> On Tue, Feb 27, 2018 at 10:48 AM, Thomas Goirand  wrote:
>>
>> On 02/23/2018 09:29 AM, Xinni Ge wrote:
>> > Hi there,
>> >
>> > We are aware of the javascript embedded issue, and working on it now,
>> > the patch will be summited later.
>> >
>> > As for the unittest failure, we are still investigating it. We will
>> > contant you as soon as we find out the cause.
>> >
>> > Sorry to bring troubles to you. We will be grateful if you could wait
>> > for a little longer.
>> >
>> > Best Regards,
>> >
>> > Xinni
>>
>> Hi,
>>
>> Thanks for this message. This lowers the frustration! :)
>> Let me know if there's any patch I could review.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> __
>> 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
>
>
>
>
> --
> 葛馨霓 Xinni Ge
>
> __
> 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 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

Re: [openstack-dev] [cinder] about clone the volume

[李杰]

Thank you
 
-- Original --
From:  "Ivan Kolodyazhny";
Date:  Fri, Mar 2, 2018 05:40 PM
To:  "OpenStack Developmen"; 

Subject:  Re: [openstack-dev] [cinder] about clone the volume

 
Hi Lijie,


We use Create Volume API for this with 'source_volid' param. It's available in 
Rest API and cinderclient.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/



 
On Fri, Mar 2, 2018 at 8:31 AM, 李杰  wrote:
Hi,all


  This is the spec [0] about clone a volume.And I find the clone function 
in cinder driver.py.But I don't know why we don't provide a restful  api about 
it.Can you tell me more about this ?Thank you very much.
  The link is here.
  
Re:https://blueprints.launchpad.net/cinder/+spec/add-cloning-support-to-cinder














Best Regards
Lijie



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

Re: [openstack-dev] [cinder] about clone the volume

[Ivan Kolodyazhny]

Hi Lijie,

We use Create Volume API for this with 'source_volid' param. It's available
in Rest API and cinderclient.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Fri, Mar 2, 2018 at 8:31 AM, 李杰  wrote:

> Hi,all
>
>   This is the spec [0] about clone a volume.And I find the clone
> function in cinder driver.py.But I don't know why we don't provide a
> restful  api about it.Can you tell me more about this ?Thank you very much.
>   The link is here.
>   Re:https://blueprints.launchpad.net/cinder/+spec/
> add-cloning-support-to-cinder
>
>
>
>
>
>
>
> Best Regards
> Lijie
>
> __
> 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 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

Re: [openstack-dev] [tripleo] storyboard evaluation

[Emilien Macchi]

A quick update:

- Discussed with Jiri Tomasek from TripleO UI squad and he agreed that his
squad would start to use Storyboard, and experiment it.
- I told him I would take care of making sure all UI bugs created in
Launchpad would be moved to Storyboard.
- Talked with Kendall and we agreed that we would move forward and migrate
TripleO UI bugs to Storyboard.
- TripleO UI Squad would report feedback about storyboard to the storyboard
team with the help of other TripleO folks (me at least, I'm willing to
help).

Hopefully this is progress and we can move forward. More updates to come
about migration during the next days...

Thanks everyone involved in these productive discussions.

On Wed, Jan 17, 2018 at 12:33 PM, Thierry Carrez 
wrote:

> Clint Byrum wrote:
> > [...]
> > That particular example board was built from tasks semi-automatically,
> > using a tag, by this script running on a cron job somewhere:
> >
> > https://git.openstack.org/cgit/openstack-infra/zuul/
> tree/tools/update-storyboard.py?h=feature/zuulv3
> >
> > We did this so that we could have a rule "any task that is open with
> > the zuulv3 tag must be on this board". Jim very astutely noticed that
> > I was not very good at being a robot that did this and thus created the
> > script to ease me into retirement from zuul project management.
> >
> > The script adds new things in New, and moves tasks automatically to
> > In Progress, and then removes them when they are completed. We would
> > periodically groom the "New" items into an appropriate lane with the
> hopes
> > of building what you might call a rolling-sprint in Todo, and calling
> > out blocked tasks in a regular meeting. Stories were added manually as
> > a way to say "look in here and add tasks", and manually removed when
> > the larger effort of the story was considered done.
> >
> > I rather like the semi-automatic nature of it, and would definitely
> > suggest that something like this be included in Storyboard if other
> > groups find the board building script useful. This made a cross-project
> > effort between Nodepool and Zuul go more smoothly as we had some more
> > casual contributors to both, and some more full-time.
>
> That's a great example that illustrates StoryBoard design: rather than
> do too much upfront feature design, focus on primitives and expose them
> fully through a strong API, then let real-world usage dictate patterns
> that might result in future features.
>
> The downside of this approach is of course getting enough usage on a
> product that appears a bit "raw" in terms of features. But I think we
> are closing on getting that critical mass :)
>
> --
> Thierry Carrez (ttx)
>
> __
> 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
>



-- 
Emilien Macchi
__
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

Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week ?

[Patil, Tushar]

Hi Grey,

We are waiting on right side of croke park hotel reception.

Regards
Tushar


From: Waines, Greg 
Sent: Friday, March 2, 2018 4:40:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week 
?

Sounds good ... see you there.
Greg.

From: "Patil, Tushar" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, March 1, 2018 at 7:32 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week 
?

Hi Greg,

We can meet near croke park hotel reception at 9:00am. Is it ok?

Regards
Tushar


From: Waines, Greg >
Sent: Friday, March 2, 2018 1:45:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week 
?

I’m available ... where will we meet up ?
Greg.

From: "Patil, Tushar" 
>
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Thursday, March 1, 2018 at 4:41 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week 
?


Hi All,



Can we meet tomorrow morning between 9:00 and 10:00 A.M?



Regards,

Tushar Patil


From: Sam P >
Sent: Thursday, March 1, 2018 11:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week 
?

Hi All,
Really sorry, I couldn't make it to PTG. However, as Dinesh said some team 
members are at PTG.
I can connect on Zoom or Skype or Hangout... etc. Let me know the time if you 
are meeting up..
Thanks..


--- Regards,
Sampath


On Thu, Mar 1, 2018 at 8:03 AM, Adam Spiers 
>
 wrote:
My claim to being a masakari person is pretty weak, but still I'd like
to say hello too :-)  Please ping me (aspiers on IRC) if you guys are
meeting up!


Bhor, Dinesh 
>
 wrote:
Hi Greg,


We below are present:


Tushar Patil(tpatil)

Yukinori Sagara(sagara)

Abhishek Kekane(abhishekk)

Dinesh Bhor(Dinesh_Bhor)


Thank you,

Dinesh Bhor



From: Waines, Greg 
>
Sent: 28 February 2018 19:22:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Any masakari folks at the PTG this week ?


Any masakari folks at the PTG this week ?



Would be interested in meeting up and chatting,

let me know,

Greg.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
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 mailing list - lists.openstack.org Mailing 
Lists
lists.openstack.org
This list for the developers of OpenStack to discuss development issues and 
roadmap. It is focused on the next release of OpenStack: you should post on 
this list if ...




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [cinder] about clone the volume

[李杰]

Hi,all


  This is the spec [0] about clone a volume.And I find the clone function 
in cinder driver.py.But I don't know why we don't provide a restful  api about 
it.Can you tell me more about this ?Thank you very much.
  The link is here.
  
Re:https://blueprints.launchpad.net/cinder/+spec/add-cloning-support-to-cinder














Best Regards
Lijie__
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